Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00000%. Comparing base (3dd35d7) to head (0a66eab).
⚠️ Report is 2 commits behind head on main.

@@               Coverage Diff               @@
##                 main        #3403   +/-   ##
===============================================
  Coverage   100.00000%   100.00000%           
===============================================
  Files             128          128           
  Lines           19424        19417    -7     
  Branches         1318         1316    -2     
===============================================
- Hits            19424        19417    -7     

I've added a change that allows trio.CancelScope to switch from being relative to absolute. I know this wasn't the original design, but thinking through the deprecation note made this seem like a good change. I'd be happy to remove this change, I've kept it in a separate commit so we can revert it easily.

I've added a change that allows trio.CancelScope to switch from being relative to absolute. I know this wasn't the original design, but thinking through the deprecation note made this seem like a good change. I'd be happy to remove this change, I've kept it in a separate commit so we can revert it easily.

I think this is slightly footgunny:

with trio.CancelScope(relative_deadline=7) as cs:
  ...
  # nvm we want delay it 10 seconds
  cs.deadline = 10
  # oops now we instantly cancel

the properties are so similarly named, that I think it could be easy to mistakenly type one instead of the other, or overlook/get confused when reading the code. And I don't think it's a necessary API since if you really want to "switch type" you can do so explicitly by doing simple math with trio.current_time().
The biggest reason I can see is if you're passing around a CancelScope that you don't know if it's relative or not, and we want to avoid the hassle of checking CancelScope.is_relative/introduction of bugs by forgetting to check it.